Skip to content

Using configureEach instead of all to avoid unnecessary configuration #42020

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Using configureEach instead of all to avoid unnecessary configuration #42020

wants to merge 1 commit into from

Conversation

quaff
Copy link
Contributor

@quaff quaff commented Aug 25, 2024

Resolving all configurations is usually bad practice, because it might trigger work that could be avoided, which will make the build slower.

@quaff
Using configureEach instead of all to avoid unnecessary configura…
c76f481 
…tion

Resolving all configurations is usually bad practice, because it might trigger work that could be avoided, which will make the build slower.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 25, 2024
@philwebb philwebb changed the title Using configureEach instead of all to avoid unnecessary configuration Using configureEach instead of all to avoid unnecessary configuration Aug 27, 2024
@philwebb philwebb requested a review from wilkinsona August 27, 2024 03:06
@philwebb philwebb added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Aug 27, 2024
@philwebb philwebb added this to the 3.2.x milestone Aug 27, 2024
@wilkinsona
Copy link
Member

For tasks, using configureEach is recommended as it avoids eager creation of tasks that have been lazily registered. As far as I know, the same does not apply to configurations as there's no support for lazy registration. Furthermore, I don't think changing from all to configureEach has any bearing on whether or not the configuration is resolved and Gradle's own documentation uses configurations.all in places. Given this, I'm going to close this one as I don't think it will bring any noticeable benefit. Thanks anyway.

@wilkinsona wilkinsona closed this Aug 28, 2024
@wilkinsona wilkinsona removed this from the 3.2.x milestone Aug 28, 2024
@wilkinsona wilkinsona added the status: declined A suggestion or change that we don't feel we should currently apply label Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@wilkinsona wilkinsona Awaiting requested review from wilkinsona

Assignees
No one assigned
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: task A general task
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@quaff @wilkinsona @philwebb @spring-projects-issues